Systems and methods for resolving telephone number discrepancies en masse

ABSTRACT

A method of correcting telephone number status discrepancies using a telephone number inventory management system includes providing a telephone number inventory management system. In the system, each telephone number in a plurality of telephone numbers is represented by an active data record. The active data records comprise data representing the telephone number and data representing a rule relating to the telephone number. The rule relating to the telephone number is selected from a list of rules. Each rule represents a unique combination of actual states for telephone numbers among a plurality of data environments. The method also includes identifying a specific rule that reflects a discrepancy among the plurality of data environments, searching the active data records for telephone numbers relating to the specific rule, and transmitting from the telephone number inventory management system a command to one of the plurality of data environments to change the status of each of the telephone numbers relating to the specific rule.

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application is related to co-pending, commonly assigned, andconcurrently filed U.S. patent application Ser. No.______, entitled“SYSTEMS AND METHODS FOR MANAGING TELEPHONE NUMBER INVENTORY” (AttorneyDocket No. 020366-088100), and to co-pending, commonly assigned, andconcurrently filed U.S. patent application Ser. No.______, entitled“SYSTEMS AND METHODS FOR MANAGING LARGE DATA ENVIRONMENTS” (AttorneyDocket No. 020366-088200), and to co-pending, commonly assigned, andconcurrently filed U.S. patent application Ser. No.______, entitled“SYSTEMS AND METHODS FOR RESTRICTING A TELEPHONE NUMBER'S AVAILABILITYFOR ASSIGNMENT” (Attorney Docket No. 020366-088300), and to co-pending,commonly assigned, and concurrently filed U.S. patent application Ser.No.______, entitled “SYSTEMS AND METHODS FOR CLEARING TELEPHONE NUMBERPORTING ASSIGNMENTS EN MASSE” (Attorney Docket No. 020366-088400), whichapplications are incorporated herein by reference in their entirety forall purposes.

BACKGROUND OF THE INVENTION

[0002] The present invention relates generally to data managementsystems. More specifically, the present invention relates to systems andmethods for storing, manipulating, and accessing data in data managementsystems.

[0003] In many business environments, data management systems haveevolved along with the business. As new needs for maintaining dataarise, the business typically modifies existing systems to satisfy thenew need. It is common, however, for a need to arise that overwhelms thecapacity of existing systems or taxes its original design scope ofoperation. This may occur for many reasons. For example, operationalsupport systems are not typically designed for data reporting, yet newrequirements may depend on reporting on the data such systems maintain.Further, the need for data reporting may require information fromdifferent systems in which the needed information is maintaineddifferently. Further still, historical reporting may be needed fromsystems not designed to maintain historical data. In such cases, theeffort to efficiently access the data for the reports may requiremodifications beyond the capability of the present systems. As anotherexample, it may be the case that the sheer volume of data stored indiverse systems makes efficiently accessing the data difficult. Dataqueries may require too much time to process, rendering the systemsunacceptable for new tasks. In yet another example, it may be impossibleto obtain accurate data in multiple dynamic systems because theinformation may change before the necessary information is obtained fromeach of the systems. In other words, the data in the various systems maynot be point-in-time synchronized. For these reasons, new methods ofaccessing data from different systems are needed. Further, new methodsof working with the data are needed.

BRIEF SUMMARY OF THE INVENTION

[0004] Embodiments of the present invention thus provide a method ofcorrecting telephone number status discrepancies using a telephonenumber inventory management system. The method includes providing atelephone number inventory management system. In the system, eachtelephone number in a plurality of telephone numbers is represented byan active data record. The active data records include data representingthe telephone number and data representing a rule relating to thetelephone number. The rule relating to the telephone number is selectedfrom a list of rules. Each rule represents a unique combination ofactual states for telephone numbers among a plurality of dataenvironments. The method also includes identifying a specific rule thatreflects a discrepancy among the plurality of data environments,searching the active data records for telephone numbers relating to thespecific rule, and transmitting from the telephone number inventorymanagement system a command to one of the plurality of data environmentsto change the status of each of the telephone numbers relating to thespecific rule. In some embodiments, one of the data environments relatesto a telephone number inventory system, which may be a Customer NumberManager product. One of the data environments may relate to a telephonenumber porting management system, which may be an Advanced ServiceManagement System. One of the data environments may relate to a serviceorder system. One of the data environments may relate to a system thatmanages data relating to central office facilities and circuits.

[0005] In other embodiments, a system for correcting telephone numberstatus discrepancies includes a host computer system. The host computersystem is programmed to manage data relating to telephone numbers. Eachtelephone number in a plurality of telephone numbers is represented byan active data record. The active data records include data representingthe telephone number and data representing a rule relating to thetelephone number. The rule relating to the telephone number is selectedfrom a list of rules. Each of which rules represents a uniquecombination of actual states for telephone numbers among a plurality ofdata environments. The host computer system is further programmed toreceive information identifying a specific rule that reflects adiscrepancy among the plurality of data environments, search the activedata records for telephone numbers relating to the specific rule, andtransmit a command to one of the plurality of data environments tochange the status of each of the telephone numbers relating to thespecific rule.

[0006] In still other embodiments, a telephone number inventorymanagement system includes a host computer system that is programmed tomanage data relating to telephone numbers. Each telephone number in aplurality of telephone numbers is represented by an active data record.The active data records includes data representing the telephone numberand data representing a rule relating to the telephone number. The rulerelating to the telephone number is selected from a list of rules. Eachrule represents a unique combination of actual states for telephonenumbers among a plurality of data environments. The host computer systemalso includes receiving means for receiving information identifying aspecific rule that reflects a discrepancy among the plurality of dataenvironments, searching means for searching the active data records fortelephone numbers relating to the specific rule, and transmitting meansfor transmitting a command to one of the plurality of data environmentsto change the status of each of the telephone numbers relating to thespecific rule.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A further understanding of the nature and advantages of thepresent invention may be realized by reference to the remaining portionsof the specification and the drawings wherein like reference numeralsare used throughout the several drawings to refer to similar components.Further, various components of the same type may be distinguished byfollowing the reference label by a dash and a second label thatdistinguishes among the similar components. If only the first referencelabel is used in the specification, the description is applicable to anyone of the similar components having the same first reference labelirrespective of the second reference label.

[0008]FIG. 1 illustrates a data management system according toembodiments of the present invention.

[0009]FIG. 2 illustrates a method of managing data in a data managementsystem, such as the system of FIG. 1.

[0010] FIGS. 3A-D illustrate data management methods according toembodiments of the present invention.

[0011]FIGS. 4A and 4B illustrate methods for performing queries on datamanaged according to embodiments of the present invention.

[0012]FIGS. 5A and 5B illustrate embodiments of an interactive userinterface for reporting to a user information relating to datamaintained according to embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0013] According to the present invention, it becomes possible toefficiently access data that is maintained across multiple dataenvironments. The data may be maintained differently in each of the dataenvironments. The data also may be dynamic. The present invention isparticularly useful in data management systems having very large volumesof data, for example, census data systems, telephone number inventorymanagement systems, and the like.

[0014] In general, according to the present invention, the processbegins by identifying information of interest relating to stored dataitems. According to a non-limiting example of the present invention, thedata items are telephone numbers (TNs) and the information of interestis the status of each TN. A data environment is a system of one or morecomputing devices and/or data storage devices. Several examples of dataenvironments will be described in more detail hereinafter. Although a TNmanagement system will be used herein as a specific example to which theteachings of the present invention may be applied, the present inventionis in no way limited to TN management systems. The teachings of thepresent invention may be applied to many other types of systems.

[0015] TN inventory management is a critical function of many telephoneservice providers. TNs are a finite resource, and their use andavailability are regulated by the Federal Communications Commission(FCC). As the telephone network has evolved over the years, the systemsthat operate the network have been designed to operate according tospecific standards. For example, the present standard provides for sevendigit dialing to reach customers within most local telephone areas, andten digit dialing to reach other customers, at least within the nationaltelephone network (i.e., the public switched telephone network, PSTN).As such, TNs are ten digit numbers. The ten digits are segmented into anumber plan area (NPA), typically representing a geographic area, anexchange (NXX) representing a central office, and a four digit “line.”Thus, any U.S. TN's format may be expressed as NPA-NXX-LINE.

[0016] The North American Numbering Plan Administrator (NANPA) is theorganization that releases TNs to telephone service providers. NANPAheretofore has released TNs in blocks of 10,000. Because TNs may beexhausted at the current rate of release by NANPA to telephone serviceproviders, the FCC has implemented several initiatives to ensure acontinuous TN supply. One such initiative may ultimately add additionaldigits to each TN. Because of the numerous changes to present telephonenetworks needed to accommodate the additional digits, this initiativewould take many years to implement. Some sources opine that implementingthis initiative would dwarf the Y2K initiative in complexity. A secondinitiative is the Numbering Resource Optimization (NRO) order 00-104(hereinafter “the number pooling mandate”). The number pooling mandaterequires TN management in blocks of 1,000, and imposes reportingrequirements on telephone service providers detailing the serviceprovider's inventory in terms of TN status. These reports willfacilitate the donation of TNs in blocks of 1,000 to a TN pool so thatthe TNs may be allocated to other service providers. In this way, theFCC hopes to prolong the usage of ten-digit TNs by minimizing “wasted”TNs.

[0017] Unfortunately, the number pooling mandate requires reporting ofstatus information according to FCC-defined categories that, in mostcases, do not relate to categories used by telephone service providers.Thus, present TN inventory management systems cannot easily generate thereports needed to satisfy the number pooling mandate. Further,information from other data environments that may affect a TN's statusvis-a-vis the FCC-mandated categories must be included to produceaccurate reports.

[0018] Continuing with the example of a TN management system, the“status” of a TN refers to a TN's present state of usage. For example, aTN may be assigned to a residential customer or a business customer; itmay be configured for voice communication or data communication; it maybe reserved for a future, specific customer; it may be “ported” from anoriginal switch through a number of intermediate switches to adestination switch; it may be the subject of a pending service order; itmay also be available for assignment to a customer. Many other examplesare possible. According to the present invention, many different dataenvironments may maintain data relating to any particular TN's status,some of which do not include a “status” variable. In such systems, thestatus must be derived from other information. In this example, however,the number of different possibilities for a TN's status is finite ineach of the data environments, even though the possibilities may bedifferent in each of the environments.

[0019] Continuing with this example, data is loaded from each of severaldata environments into a common data management system. It is notnecessary to load all the data stored in each of the data environments;the data loaded from the data environments may be limited to the dataneeded in further operations. It may be necessary at this point,however, to map data from one or more of the data environments into aconsistent format. Further, it may be necessary to derive values forcertain variables from data maintained in one or more of the dataenvironments. In other words, the process of loading data from the dataenvironments into the data management system may involve some datamanipulation. For example, for some data environments it may benecessary to derive each TN's status from other data maintained by thedata environment if that data environment has no concept of status.

[0020] The data from the data environments are loaded into records, eachrecord representing the data applicable to a TN in a data environment.Thus, each TN may have more than one record. The records into which datais loaded may include a start field that identifies the earliest pointin time for which the data applies to the TN of the record. Each recordalso may include an end field that identifies the latest point in timeto which the data applies to the TN of the record. The end field may beempty when the record is first created. As will be explained furtherbelow, the end field may be written with a date when data applicable toa given TN changes. Thus, records may be considered “open” until the endfield is filled, after which the record is closed. In this way openrecords for a TN identify a TN's present status, while closed recordsidentify a TN's historical status. The records are then saved for futureuses.

[0021] Future uses for records may include: reports relating to thestatus of all TNs in the system; a query relating to the status of aspecific TN in a specific system; a query relating to TNs that havechanged status in a given period of time; and the like. Many otherexamples are possible, some of which will be explained in more detailhereinafter.

[0022] Periodically, the records may be updated to reflect changes toeach TN's data. This is accomplished by comparing each TN's data in eachdata environment to the TN's data in the open records. Alternatively oradditionally, this may be accomplished by reading the data from the dataenvironments into the common data management system and comparing thenew data to the data read previously. A report of changes may then beused to update the records. Other possibilities for updating the recordsexist, and different update processes may be applied to each dataenvironment.

[0023] As explained previously, when data relating to an item changes,the record may be closed by writing in the end field the last date forwhich the previous data applied to the item and opening a new recordreflecting the new data, including a new beginning date in the startfield. The new and modified records are then saved for future use asexplained above. The updating process, which opens new records andcloses old records, is particularly useful in that it provides a compactand efficient process for maintaining historical data relating to eachitem. It is often the case that the data environments, often burdenedwith the task of maintaining large volumes of additional data, do notmaintain historical data. Thus, in addition to solving the problem ofrelating data across many different systems, the present inventionprovides historical reporting capabilities.

[0024] It should be noted that the order of opening, closing, and savingrecords is not limited to that described above. Records may be saved atany time in relation to the process of opening and closing them andcomparing the information relating to other records. In light of thedisclosure herein, those skilled in the art will realize many differentapproaches to carrying out the specific tasks outlined above.

[0025] With respect to the present example relating to TNs, the recordsmay include name and address information relating to the currentcustomer to which a TN is assigned. It is also possible to maintainother information in the records so that queries on the records may beaccomplished efficiently. For example, the present switch to which a TNis assigned may be maintained in the record for a TN. It is alsopossible, however, to construct queries that obtain information from thestored records and then extract additional information from one or moreof the data environments. Those skilled in the art will realize manyadditional possibilities for manipulating data and extractinginformation from the data management system in light of the disclosureherein. Thus, the present invention is not limited to the specificexamples described herein.

[0026] The present invention also provides a process for updating statusinformation from the data management system to one or more of the dataenvironments. This synchronizing process, which will be described inmore detail hereinafter, may become necessary because one or more of thedata environments do not maintain complete and/or accurate informationon all items (e.g., TNs). Thus, during the record updating process, thedata environment may no longer provide information on an item on whichit previously reported. However, the record may remain open in the datamanagement system. Thus, occasional correction of “data drift” may benecessary or desirable.

[0027] According to the present invention, rules may be used to furtherstreamline the process of obtaining information from the data managementsystem. For example, a set of rules may be established, each rule beinga key that represents a TN's status in each of the data environments.Because a TN has a finite number of possibilities for its status in eachdata environment, it is possible to establish a complete set of rulesthat identify all possible status combinations across all dataenvironments. For example, if TNs have three status possibilities in onedata environment, four in a second data environment, and two in a thirddata environment, twenty-four rules (3×4×2=24) will describe thecombined status of all TNs across the three data environments.

[0028] Although the number of possibilities for a TN's status in eachsystem is finite, the number of possibilities may change. For example,if a third possibility is added for the status of a TN in the third dataenvironment, then twelve additional rules may be added to allow for theadditional possibilities for each TN's overall status. Likewise, if anew data environment is added, new rules may be added to account for theadditional possibilities for a TN's status in the additional system.Thus, the present invention is not limited to an initial, fixed numberof rules.

[0029] Once the rules are established, records may be created thatinclude each TN and the rule that defines the TN's status across alldata environments. Thus, whereas the data management system previouslyincluded multiple records for each TN, as many as one per dataenvironment, the rules-based records condense the status informationinto a single record for each TN.

[0030] According to the present invention, the information of interestmay change to adapt to new requirements. As will be described in moredetail hereinafter, the present invention includes a rules-load processwherein rules that relate to the new information of interest are loaded.Thus, the present invention is dynamic with respect to changing needs.Further, additional rules sets relating to other information of interestmay be loaded, thus adding additional dimensions to the data managementprocess.

[0031] The present invention provides additional desirable features. Forexample, the creation of rules relating to the information of interestallows management of the items at the rule level, rather than the itemlevel. In the case of TNs, if a particular rule reflects an overallstatus across the several data environments known to create conflicts,an occurrence of the rule may generate a flag signaling a potentialproblem that may be worked prior to the occurrence of the conflict. Aspecific example of this would be a TN that is identified as “assigned”to a customer in one data environment but that is listed as “available”in another data environment. Rules that reflect conflicts also may beassigned a specific person or organization of responsibility. Thisresponsible party may receive a message alerting it to the presence of apotential problem. In still a further extension of this capability, theitem to which the rule applies may be blocked or otherwise protectedautomatically, pending resolution, such that the potential problem isavoided. These and many other features and benefits of the presentinvention will be explained in more detail hereinafter.

[0032] Having described the present invention generally, attention isdirected to FIG. 1, which illustrates a specific example of a datamanagement system 100 according to an embodiment of the presentinvention. The system 100 relates to a TN management system. As statedpreviously, although a TN management system is used for illustrativepurposes to demonstrate the elements, features, and benefits of thepresent invention, the present invention is in no way limited to a TNmanagement system. The system 100 includes a plurality of dataenvironments 102, and a host computer system 104. Each of the pluralityof data environments 102 communicates with the host computer systemthrough a network 106. The data environments 102 may comprise adatabase, a computing device, one or more terminals for accessing datamaintained in the data environment, other computer peripherals, and/orthe like. Specific examples of the data environments 102 will beprovided hereinafter.

[0033] The host computer system 104 may be any computing device orcomputing system. For example, the host computer system 104 may includea server computer 108, a database server 110, a web server 112, and/orthe like. The various components of the host computer system may beco-located at a single geographic area or may be distributed throughoutmany different geographic locations, as is known in the art. In fact,the host computer system 104 and the data environments 102 may bedistributed throughout a number of different geographic areas orco-located at a single location. In some embodiments, the various dataenvironments 102 and the host computer system 104 comprise a singlecomputing device. Many other examples are possible, all of which arewithin the scope of the present invention.

[0034] The network 106 may be any wireless or wired network, includingan optical network, a local network, an Ethernet, a local area network,a virtual private network, a wide area network, the Internet, and/or thelike, or any combination of the foregoing. Many other examples arepossible.

[0035] The data management system 100 also may include one or morecomputing devices 114 that provide user access to the various componentsof the data management system 100. The computing devices 114 may be workstations, desktop computers, laptop computers, personal digitalcomputers, terminals, and the like. The computing devices 114 may accessthe various components of the data management system 100 via the network106, or the computing devices 114 may be connected directly to any oneor more of the components.

[0036] The host computer system 104, the data environments 102, and thecomputing devices 114 each may include application software thatprograms the device to perform the methods of the present invention. Forexample, the server computer 108 of the host computer system 104 may beprogrammed to create records containing TNs and the rules that describethe status of the each TN.

[0037] According to this specific, non-limiting example of the presentinvention, the data environment 102-1 may be a TN inventory managementsystem. One such commercial version of a TN inventory management systemis called Customer Number Manager (CNUM), a product of TelcordiaTechnologies, Inc. of Morristown, N.J. The TN inventory managementsystem 102-1 may-be the primary'system for a telephone company to manageits TN inventory, although other data environments also may affect aTN's status.

[0038] As stated previously, the number pooling mandate requiresmanagement of TNs according to FCC-defined categories relating tostatus. Because the FCC-mandated categories do not relate to categoriestypically used by telephone service providers, present TN inventorymanagement systems, such as the CNUM system 102-1 of FIG. 1, cannoteasily generate the reports needed to satisfy the number poolingmandate. Such operational support systems were simply not designed forreporting. Further, information from other data environments 102 thatmay affect a TN's status must be included to properly report on TNinventory.

[0039] A second data environment that may affect a TN's status accordingto the FCC-defined categories is a porting management system 102-2.“Porting” refers to Local Number Portability (LNP) the process forreassigning a TN from one central office switch to another, possiblythrough a series of switches. Porting often occurs when a customerrelocates to a new home or business still within their telephone serviceprovider's service area. If the customer wishes to keep his oldtelephone number at his new location, the number must be “ported” to thenew location if the telephone switch that serves the customer's newlocation is different from the one serving his previous location. When acall is placed to a ported TN, instead of being routed to the switch towhich the TN was allocated originally, a porting assignment ensures thatthe call is routed to the proper location.

[0040] A porting management system 102-2 creates and administers portrequests. One specific example of such a system is the Advanced ServiceManagement System (ASMS). The porting management system 102-2 also mayactivate port requests and interface with internal organizationsrelating to porting administration. Whether a TN is ported and to whereit is ported may affect to which of the FCC-defined status categories aTN belongs. It may also be the case, however, that, irrespective of thenumber-pooling mandate, a telephone service provider wishes to relateinformation on ported TNs with other TN information maintained in otherdata environments. Therefore, this specific example of the presentinvention includes the porting management system 102-2.

[0041] This specific example of the present invention also includes oneor more service order systems 102-3. The service order system 102-3collects service orders and service order-related data from one or moreservice order processing systems and retains the information for aperiod of time. As with the previously-described data environments,information in the service order system 102-3 may affect a TN's status,or may need to be related to TN information maintained in other dataenvironments 102 with respect to the number pooling mandate.

[0042] The TN management system 100 also includes a central officeinformation system 102-4. One example of such as system is known asSWITCH. The central office (CO) information system 102-4 storesinformation associated with central office facilities and circuits. Itprovides inventory and flow-through assignment to support line- andtrunk-side CO provisioning of digital, analog, and packet switchingfacilities. The CO information system 102-4 may include TN status data,and is, therefore, included in the TN management system 100.

[0043] The TN management system 100 also may include a provisioningsystem 102-5. The provisioning system programs the telephone networkaccording to customer orders. The TN management system 100 also mayinclude a customer record database 102-6, which stores informationrelating to customer accounts, and/or a repair database 102-7, whichmaintains records of customer repair orders. Other data environmentsalso may be included.

[0044] Having described an example of a system according to the presentinvention, attention is directed to FIG. 2, which illustrates an exampleof a method 200 according to the present invention. The method 200 maybe implemented in the data management system of FIG. 1. The method 200relates to TN inventory management by way of example. As with the TNmanagement system 100 described with respect to FIG. 1, however, themethod 200 should not be considered limited to a TN inventory managementmethod.

[0045] According to the method 200, at operation 202 information ofinterest relating to items in a data management system is identified.The information of interest may be expressed as a variable having anumber of possible values. In this case, the items are TNs and theinformation of interest is each TN's status. Also at this operation, adata representation for the records that will store the data isdesigned. The specific design format may depend on the particularsoftware used to operate the system. For example, the present inventionmay be designed in any of several well known commercial database orspreadsheet programs. In one specific embodiment, the method is carriedout using Oracle database software; however, other programs also may beused, including Microsoft Access, DB2, and Microsoft Excel. It also maybe the case that the present invention is embodied in a custom softwareprogram. Many other examples are possible, as is evident to those ofskill in the art. In some embodiments of the present invention, therecords comprise data tables having fields for each TN, the variablethat describes a TN's status, a start date for the data, an end date forthe data, the switch containing the TN, the name and address of thecustomer to whom the TN is assigned, the TN's usage, and the like. Italso may be the case that a different data representation is used foreach of several data environments.

[0046] At operation 204, data is loaded from each of a plurality of dataenvironments into a data management system. In this example of thepresent invention, the data is loaded from the data environments 102 ofFIG. 1 into the host computer system 104. The data will include theitems, as well as the information of interest. In this case, each TN isloaded, along with the information necessary to determine each TN'sstatus, among other things.

[0047] It may be the case that special mapping and translation of datais required to accomplish operation 204. For example, if different dataenvironments operate according to different data standards or includedifferent data formatting, it may be necessary to “map” the data into anew format. This may be necessary for other reasons as well. In someembodiments, the data mapping is accomplished at a different point inthe process, as will be described. It may also be the case that theinformation of interest must be derived from other data stored in thedata environment. Thus, operation 204 also may include deriving a TN'sstatus in this specific example.

[0048] At operation 206, rules are identified and loaded. The rulescomprise all possible combinations of TN statuses, which may have arange of possible values in each of the data environments. The rulesload process may be accomplished by, for example, listing the rules on aspreadsheet and loading the spreadsheet as data. In this way, the rulesmay be modified, as necessary, if data environments are added or theinformation of interest changes. Further, multiple rules sets may beused simultaneously, each operating on different information ofinterest. In such cases, compound searches of the data may be carriedout efficiently.

[0049] At operation 208, the rule relating to the information ofinterest is determined, and a record is created for each item. In thiscase, a record is opened for selected TNs, and the applicable rulehaving the particular combination of statuses for the TN is included inthe record. At this operation, if not accomplished previously, the datafrom the various data environments may require mapping into the commonformat. Also at this operation, a start date for the opening of therecord may be determined and written into the record. Other data alsomay be written into the records at operation 208. The records are thenstored for further uses.

[0050] It should be noted at this point that the order in whichoperations or sub-operations are performed is not necessarily important.For example, the saving of records may take place immediately after eachrecord is created, or after the creation of any number of records. It isto be understood, therefore, that the present invention includes withinits scope the carrying out of the operations and sub-operationsaccording to the present invention in orders other than in this example.Further, other examples of the present invention may include additionaloperations or not include some of the operations described herein. Thus,the scope of the present invention should be determined according to theclaims that follow this description.

[0051] The method of the present invention may continue at operation 210or at operation 212. At operation 210, the records are updated. Theupdating process includes loading from one or more of the dataenvironments any data that has changed. If necessary, the data may bemapped at this point or at a future point, as previously described withrespect to operations 204 and 208. If the data has not changed, therecord remains open. If the data has changed, then the record is closed,noting the end date for the previous data, and a new record is openedwith the new data and new start date. Each record is saved for futureuse.

[0052] The updating process of operation 210 also includes purging oldrecords, if desirable. To increase the efficiency of accessing data,older data may be deleted, archived, or otherwise removed from the datamanagement system. For example, in some embodiments, records having anend date older than five years may be deleted. In some embodiments, onlyopen records are maintained. In still other embodiments, the records aremaintained indefinitely. Many examples are possible. It also may be thecase that older records are merely removed to a secondary storage area.The data management system may be configured to search different storagelocations in a hierarchy such that data most likely to be needed isstored in a primary location that is searched first, while data lesslikely to be needed is stored in secondary locations. Many otherexamples are possible and apparent to those of skill in the art in lightof this disclosure.

[0053] At operation 212, the stored records may be used for a variety ofuseful purposes, several of which will be described in more detailbelow. For example, in the case of the TN inventory management system,the information may be used to report TN status to NANPA according tothe number-pooling mandate.

[0054] The method of the present invention also may continue atoperation 214. At operation 214, “data drift” may be correctedperiodically. In some embodiments of the present invention, operation214 may not be necessary. In the example of a TN inventory managementsystem described thus far, however, operation 214 typically isnecessary.

[0055] Because of the way data is loaded from the various dataenvironments and updated periodically, records may be created and neverclosed. For instance, in a porting management system, such as theporting management system 102-2 described above with respect to FIG. 1,data may not be maintained on non-ported TNs. That is, the system mayonly store information relating to ported TNs. If a previously-ported TNbecomes no longer ported, if, for example, the customer cancels service,then the porting management system no longer stores data relating to theTN. During the updating process, in the absence of data relating to aTN, the rule applicable to a TN does not change. Therefore, TNs maycontinue to appear to be ported in the data management system eventhough they are not. Conversely, it may be the case that a customercancels service of a ported TN, but the porting assignment is nevercleared. The TN is available for use by another customer, but thepresence of a porting assignment causes the TN to appear in use.Further, data may be incorrectly entered into one of the dataenvironments, resulting in bad data being read into the data managementsystem. Further still, data may be updated in a data environment withoutresetting a “last edited” or similar field that would alert the datamanagement system of the need to load the changed data. Many otherevents may result in the presence of bad data in either the source dataenvironment of the data management system. Thus, a periodic updating ofthe data environments with information from the data management systemat operation 214 may resolve these and other data drift issues.

[0056] Attention is directed to FIG. 3A, which illustrates a firstexample of a use to which the present invention may be applied. The useis embodied in a method 300 that may be a continuation of the method 200of FIG. 2. For example, the method 300 may proceed at operation 212 ofFIG. 2. In fact, this is the case with each of the examples describedbelow with respect to FIGS. 3A-3D. The method 300 relates to reportingTN status information.

[0057] TN status information may be reported to any entity authorized toreceive the information. The reports may be made available via anetwork, such as the Internet, wherein the information may be displayedon monitors associated with computers connected to the network. Inanother example, the information may be printed and submitted as areport to a requesting agency such as NANPA. Many other examples arepossible.

[0058] The method 300 begins at operation 302 wherein items andinformation of interest are read into a data management system,associated with rules, and stored into records according to the examplespreviously discussed. In this example of a method of reporting TN statusinformation, the items are TNs and the information of interest is eachTN's status in each of a plurality of data environments. The detailedsteps for completing this operation were described previously withrespect to FIG. 2.

[0059] At operation 304, the data is sorted, organized, and/or evaluatedto produce one or more meaningful reports. For example, the number ofTNs in each of several status categories defined by the FCC may bedetermined. This may be accomplished, for example, by identifying therules that apply to each category and counting the number of TNs thatrelate to each rule. In another example, the evaluation of the data mayrequire evaluating time periods during which particular rules relate toTNs. Many other examples are possible.

[0060] Operation 304 also may include sorting the number of TNs by theswitch at which each TN is located. The number of TNs may be furthersorted according to number plan area, state, and/or geographic location.Further still, the TNs may be sorted according to thousand-number blockto facilitate making the numbers available to a number pool according tothe FCC's number pooling mandate. Other examples are possible.

[0061] At operation 306, the data is presented to a user. The data maybe presented as a printed report or may be presented on, for example, acomputer monitor. The report presentation may take many forms. In onespecific example, the report is interactive and includes hyperlinks thatallow the user to drill down into more detailed information or otherwisenavigate through the data. One example of such an interactive report isdescribed in greater detail with respect to FIGS. 5A and 5B.

[0062] It may be the case in some examples of the present invention thatoperations 304 and 306 in effect merge into a single operation orcontinuously iterate back and forth. This may be true especially withrespect to an interactive report presented on a display screen. Forexample, in the case of a display screen having hyperlinks that alloweasy navigation through the data, each time the user follows ahyperlink, the hyperlink may execute another query of the records toobtain the information needed to present the data at the new displayscreen to which the hyperlink points. Those skilled in the art willrecognize, in light of this disclosure, how the data management systemof the present invention may function as a “backend” providinginformation to a user interface in the form of an interactive web site.The data requested by the user with each selection of a hyperlink ispulled from the backend database and presented according to theprogramming of the web page that functions as the user interface. Onlythrough a data management system such as the present invention, however,are very large data environments able to be reduced to an interactiveenvironment in which detailed information is quickly displayed.Heretofore, queries to display information such as that provided by thepresent invention took far too long to exist practically in aninteractive environment.

[0063] Attention is now directed to FIG. 3B which illustrates a secondmethod 310 that demonstrates another use to which the present inventionmay be applied. The method 310 relates to restricting a TN'savailability for assignment if a problem is discovered relating to theTN's status. This may occur, for example, when different dataenvironments conflict as to a TN's status.

[0064] If a TN's status is different in two or more data environments,significant problems may result. One of the most significant problemsoccurs when a new customer is assigned a TN that is in use by anexisting customer. At the very least, such conditions create additionalexpense, especially in telephone service provider provisioning systems.Ideally, service providers are able to provision customers' servicesautomatically. If a conflict occurs, such as a TN assigned to twocustomers simultaneously, then a service order cannot be completedautomatically. Any successful effort to identify such problems inadvance greatly increases the efficiency with which the service provideroperates. The method 310 is one such example.

[0065] The method 310 begins at operation 312 at which point data isentered into a data management system. This operation is similar to theoperation 302 of the method 300. At operation 314, one or more rules areidentified that reflect a status conflict among a plurality of dataenvironments. A status conflict might exist, for example, when a portingdata environment lists a TN as ported, while an inventory informationsystem lists the TN as available. Thus, any rule that includes these twostatus possibilities may reflect a conflict.

[0066] At operation 316, the records are searched for any TN relating tothe rules identified in operation 314. If any are discovered, atoperation 318 a message is sent to one or more of the data environmentsto restrict the availability of the TN. The restricted availability mayremain in place until the conflict is resolved, as will be explained ina few specific examples hereinafter.

[0067] The process of identifying TNs and sending the restrictavailability message may occur in a number of different ways. Forexample, when a rule is known to reflect a conflict, any TN having thestatus may result in a message being generated during the recordcreation or update process. In another example, when a rule isnewly-found to reflect a conflict, then a review of open records maygenerate messages for TNs relating to the rule. In yet another example,a specific request for information relating to a specific TN maygenerate a message if the TN relates to a known conflict rule. Manyother examples are possible.

[0068]FIG. 3C illustrates a method 320 of resolving discrepancies amonga plurality of data environments. In this example once again, thebenefits of a rules-based data management system are evident. In verylarge data environments, identifying and resolving discrepancies forindividual items is time consuming and inefficient. However, once a ruleis known to evidence a conflict, the conflict may be resolved, in manysituations, simultaneously for all items that relate to the rule. Themethod begins at operation 322 by identifying a rule that reflects aconflict among two or more data environments. At operation 324, it isdetermined what the correct data should be in one of the dataenvironments for items that relate to the rule. At operation 325, allitems relating to the rule are identified. At operation 326, a messageis sent to one of the data environments to write new data for each ofthe items that relate to the rule. FIG. 3D illustrates a more specificexample relating to a TN inventory management system.

[0069]FIG. 3D illustrates a method 330 of clearing incorrect portingassignments. As explained previously, a TN may be ported from anoriginal switch to a new switch when, for example, a customer relocatesand wishes to keep his same TN. When a call is placed to the customer'snumber, a porting management system (such as system 102-2 of FIG. 1),provides information that directs the call to the proper switch.Eventually, the customer may cancel his telephone service. It has beenreported that porting assignments are not necessarily cleared when thisoccurs. Thus, a TN may have a status of “ported” in a porting managementsystem, and a status of “available” in a TN inventory system. Thiscombination reflects a conflict because available TNs should not beported. The method 330 may be employed to correct such conflicts.

[0070] The method 330 begins at operation 332 when any rules areidentified that reflect a status of “ported” in a porting managementsystem and a status of “available” in a TN inventory system. Atoperation 334, it is determined that the TN inventory system statusshould override the porting management system status. At operation 335,all TNs relating to the rule are identified. At operation 336, a messageis sent to the porting management system to restore all TNs identifiedin operation 335 to a non-ported status. This is but one example of amethod of resolving data conflicts in large groups in rules-based datamanagement systems.

[0071] Attention is now directed to FIGS. 4A and B, which illustrateuseful purposes to which a TN inventory management system according tothe present invention may be applied. FIG. 4A illustrates a method ofidentifying “stolen” TNs according to the present invention. Telephoneservice providers, especially those that receive TNs from NANPA in largeblocks, may encounter customers who initiate service, receive a TN, thentransfer service within a short period of time to a different telephoneservice provider. This situation is harmful to the service provider inat least two ways. First, the service provider loses a TN from itsinventory. Second, the service provider incurs the expense of setting upa new customer but does not receive the long-term payback of customerlongevity. There is an explanation for this occurrence, and a potentialsolution provided by the present invention.

[0072] When a service provider receives a large block of TNs from NANPA,it is very likely that the block includes specific numbers thatcustomers desire. For example, business customers want easy-to-rememberTNs, that contain, for example, repeating numbers, number sequences, ornumbers whose related letters on a telephone keypad spell a word,phrase, or especially a trademark (i.e., vanity numbers). In order toreceive a specific TN, however, the customer must, at least initially,be a customer of the telephone service provider to whom the TN wasdistributed. Thus, it is sometimes the case that a customer willinitiate service with one service provider for the sole purpose ofobtaining a TN from the service provider's inventory. The method 400 ofFIG. 4A helps a service provider to identify such instances and policeits TN inventory.

[0073] The method 400 begins at operation 402, wherein TN inventory datais managed in a TN inventory management system according to the presentinvention. In this operation 402, it may be helpful to the presentmethod to include in the records for each TN a few additional datafields. For example, a cancelled_service field may be used to identifywhether a customer has cancelled service. A service_initiation field maybe used to identify the date a customer begins service with the serviceprovider. A date_cancelled_service field might be used to identify thedate a customer cancels service. A new_provider field might be used toidentify a telephone service provider to whom a customer transfers hisTN and service.

[0074] At operation 404, the records are queried to identify anycustomers who cancelled service within a specific number of months, forexample two months, from the initiation of service. At operation 405,the information is displayed to a user. At operation 406, the recordsalso may be queried to determine to which service providers thecustomers transferred service. At operation 407, this information isdisplayed to a user.

[0075] The method 400 illustrates yet another benefit of a rules-baseddata management system. For very large data environments, a rules-basedsystem makes it much easier to maintain historical data relating to theitems. Maintaining the information without the use of rules presents aproblem when it comes to searching for the type of information providedby the method 400.

[0076]FIG. 4B illustrates another example method 410 of a use to which arules-based TN inventory management system may be applied. The method410 provides a report of recently-canceled TNs. “Recently-canceled” maybe any user-defined period of time. In a very specific embodiment, theperiod of time is six months. This is very useful to service providersthat administer a no-call list for TNs owned by customers that do notwish to be called by solicitors. In some states, Colorado, for example,consumers may have their TN placed on a no-call list. The list ispublished every three months, and telephone solicitors may be fined forplacing calls to numbers on the list. If a customer on the no call listcancels service, however, there is no mechanism for removing the TN fromthe no call list. The method 410 provides one solution to this problem.

[0077] According to the method 410, TNs are managed in a TN inventorymanagement system, according to the present invention, at operation 412.It may be helpful, although not necessary, to include a no_call_listdata field in the records pertaining to the TNs. At operation 414, therecords are queried to determine any no call list customers whocancelled service within the previous three months. At operation 416,this information is displayed to a user. The information then may beused to remove the TNs from the no call list.

[0078] The methods of FIGS. 4A and 4B are but two examples to which theTN inventory management system of the present invention may be applied.Many other examples are possible and are apparent to those skilled inthe art.

[0079] Attention is now directed to FIGS. 5A and 5B, which illustrateexamples of display screens that may be used to visually representinformation according to the present invention. The exemplary displayscreens of FIGS. 5A and 5B relate to a TN inventory management systemsuch as the one previously described. This embodiment of the presentinvention should not be considered limited to a TN inventory managementsystem. FIG. 5A illustrates a display screen 500 that providesinformation on the rate of usage of TNs in a TN management system. Thisdisplay screen 500, as well as others described herein, may beaccessible via the Internet or other network, as is known in the art.For example, a customer service representative working at a locationother than a location that houses any portion of the TN inventorymanagement system may use a web browser to access this display screen.Security features may be employed to limit access by persons notauthorized to view the information or to limit the information eachperson may access. In another example, the display screens may be usedby a telephone service provider to report TN inventory reports to NANPAin compliance with the number pooling mandate. Many other exemplary usesof the display screen 500 are possible and apparent to those of skill inthe art in light of this description.

[0080] The display screen 500 includes a first tool bar 502 that may bespecific to a web browser used to access the display screen 500. Thedisplay screen 500 also includes a second tool bar 504 that may becustomized to the particular information being displayed. Buttons on thesecond tool bar 504 may provide navigation functions through a series ofpages, a find feature, and the like.

[0081] The display screen 500 also includes a series of location buttons506 that provide the user with information relating to the user'slocation within a data hierarchy. For instance, in the present examplerelating to TN inventory management, TNs may be arranged into groupsstarting with the highest level, “Top,” that may include, for example,all TNs, all TNs within the telephone service provider's inventory, orall TNs within the telephone service provider's inventory in a givenstate, in this case, Arizona (AZ). The next level down from the statelevel might be the area code level (i.e., NPA), in this case, 480. Belowthe area code level might be the rate center level, in this case,Phoenix. The next level below the rate center level might be the switchlevel. Thus, the information being displayed in the display screen 500,according to the location buttons 506, is a list of switches in thePhoenix rate center in the 480 area code in Arizona. The locationbuttons 506 may act as hyperlinks to allow the user to navigate up tohigher data levels in the hierarchy, and indicators 508, next to eachline of data, might allow the user to drill down to the next lower datalevel in the hierarchy to obtain more detailed information.Alternatively, the drill-down function may be provided by the entry inthe rate center column.

[0082] Each line of data in the display screen 500 of FIG. 5A providesinformation on TN inventory for a given switch. For example, line 510,the last line, provides information on TN inventory in switchPRVYAZPPDSO in the Phoenix rate center in Arizona. The informationincludes: months to exhaustion (MTE) 511, average monthly growth (AMG)512, the number of TNs assigned to the switch 513, the change from theprevious month 514, the number of TNs available for assignment 515, thechange from the previous month 516, the % utilization of TNs in theswitch 517, the number of NPA-NXXs served by the switch 518, and thenumber of 1K TN blocks received 519 and donated 520. Each of thesemetrics will be described in more detail below.

[0083] The indicators 508 in front of each line of data may also providean easy indicator of the status of each switch's inventory through colorcoding. The legend 522 provides the key to the color coding. Selectingthe indicator 508 next to the line 510 would cause the display screen525 of FIG. 5B to be displayed.

[0084]FIG. 5B illustrates a more detailed, historical representation ofthe activity with respect to TN inventory at a specific switch. Thehistorical perspective illustrates how the TN inventory at a switch haschanged over time. This view also facilitates efforts to plan forseasonal fluctuations in the number of TNs available at a switch. Thelocation buttons 506 provide the user with a visual representation ofthe user's location within the data hierarchy, as previously discussed.In this display screen 525, however, each line of data represents amonth in the life of the switch, with the exception of the last line526, which represents the present status of the switch. The data columnsin each line of display screen 525 are the same as the analogous columnfrom the display screen 500.

[0085] Referring now to both FIGS. 5A and 5B, the “available” column 515lists the number of TNs available for assignment in the switch. The“assigned” column 513 lists the number of TNs in the switch that areassigned. In the case of the display screen 500 of FIG. 5A, each entryin the Assigned column 513 relates to a different switch, while theentries in the Assigned column 513 of display screen 525 of FIG. 5Brelate to different periods of time for a particular switch.

[0086] The data to determine which TNs are assigned and which TNs areavailable may come from a query of the TN inventory management systemdiscussed previously. For example, a data field in each record of the TNinventory management system may identify the switch to which each TNbelongs. Other data field may identify whether the TN is assigned oravailable. It should be noted that the definitions of “available” and“assigned” may be selected such that they match the definitions of“available” and “assigned” according to the FCC with respect to thenumber pooling mandate. It also may be the case that a TN should beconsidered available or assigned according to the FCC definition if theTN fell into that category at any time during a previous period of time,such as six month or two years. Thus, the entire collection of recordsmay be evaluated to total the number of assigned and available numbersin each switch according to the definitions.

[0087] Continuing to refer to FIGS. 5A and B, the Assigned +/− column514 and the available +/− column 516 list the change in the number ofTNs assigned or available, respectively, from the previous month. Ofcourse, other reports could be designed that track the changes overdifferent time periods such as quarters of a year or years. The %Utilcolumn 517 lists the percentage of TNs located at the switch that areutilized according to the FCC definition.

[0088] The AMG column 512 lists the average monthly growth in assignedTNs over the preceding six months as defined by the FCC. Other averagingtime periods could be used. The MTE column 511 lists the number ofmonths until the available TNs located at a switch run out at thecurrent AMG. It is calculated by dividing the number of TNs available bythe AMG.

[0089] Thus, the information provided by FIGS. 5A and 5B providetelephone service providers easily understandable reports on TNinventory at multiple levels. The indicators 508 provide a visualindication of whether any switches are running out of numbers. By beingable to forecast TN utilization, these service providers are better ableto service customers by better managing the supply of TNs, therebyreducing the possibility that a customer desiring service will have towait for a TN to become available. Further, the information helps theservice providers to comply with FCC requirements such as the numberpooling mandate. For example, if the utilization of TNs at a given ratecenter falls below a pre-established threshold, then the serviceprovider may be asked by the FCC to release TNs in blocks of 1,000 tothe number pool. In this way, the finite supply of TNs may be extended.

[0090] Having described several embodiments, it will be recognized bythose of skill in the art that various modifications, alternativeconstructions, and equivalents may be used without departing from thespirit of the invention. Additionally, a number of well known processesand elements have not been described in order to avoid unnecessarilyobscuring the present invention. For example, those skilled in the artknow how to arrange computers into a network and enable communicationamong the computers. Additionally, those skilled in the art will realizethat the present invention is not limited to managing TN inventory. Theteachings of the present invention may be used to manage data in otherdata environments. Accordingly, the above description should not betaken as limiting the scope of the invention, which is defined in thefollowing claims.

What is claimed is:
 1. A method of correcting telephone number statusdiscrepancies using a telephone number inventory management system, themethod comprising: providing a telephone number inventory managementsystem wherein each telephone number in a plurality of telephone numbersis represented by an active data record, wherein the active data recordscomprise data representing the telephone number and data representing arule relating to the telephone number, wherein the rule relating to thetelephone number is selected from a list of rules, each of which rulesrepresents a unique combination of actual states for telephone numbersamong a plurality of data environments; identifying a specific rule thatreflects a discrepancy among the plurality of data; environments;searching the active data records for telephone numbers relating to thespecific rule; and transmitting from the telephone number inventorymanagement system a command to one of the plurality of data environmentsto change the status of each of the telephone numbers relating to thespecific rule.
 2. The method of claim 1, wherein one of the dataenvironments relates to a telephone number inventory system.
 3. Themethod of claim 2, wherein the telephone number inventory systemcomprises a Customer Number Manager product.
 4. The method of claim 1,wherein one of the data environments relates to a telephone numberporting management system.
 5. The method of claim 4, wherein thetelephone number porting management comprises an Advanced ServiceManagement System.
 6. The method of claim 1, wherein one of the dataenvironments relates to a service order system.
 7. The method of claim1, wherein one of the data environments relates to a system that managesdata relating to central office facilities and circuits.
 8. A system forcorrecting telephone number status discrepancies, comprising: a hostcomputer system programmed to manage data relating to telephone numbers,wherein each telephone number in a plurality of telephone numbers isrepresented by an active data record, wherein the active data recordscomprise data representing the telephone number and data representing arule relating to the telephone number, wherein the rule relating to thetelephone number is selected from a list of rules, each of which rulesrepresents a unique combination of actual states for telephone numbersamong a plurality of data environments, wherein the host computer systemis further programmed: receive information identifying a specific rulethat reflects a discrepancy among the plurality of data environments;search the active data records for telephone numbers relating to thespecific rule; and transmit a command to one of the plurality of dataenvironments to change the status of each of the telephone numbersrelating to the specific rule.
 9. The system of claim 8, wherein one ofthe data environments relates to a telephone number inventory system.10. The system of claim 9, wherein the telephone number inventory systemcomprises a Customer Number Manager product.
 11. The system of claim 8,wherein one of the data environments relates to a telephone numberporting management system.
 12. The system of claim 11, wherein thetelephone number porting management system comprises an Advanced ServiceManagement System.
 13. The system of claim 8, wherein one of the dataenvironments relates to a service order system.
 14. The system of claim8, wherein one of the data environments relates to a system that managesdata relating to central office facilities and circuits.
 15. A telephonenumber inventory management system, comprising: a host computer systemprogrammed to manage data relating to telephone numbers, wherein eachtelephone number in a plurality of telephone numbers is represented byan active data record, wherein the active data records comprise datarepresenting the telephone number and data representing a rule relatingto the telephone number, wherein the rule relating to the telephonenumber is selected from a list of rules, each of which rules representsa unique combination of actual states for telephone numbers among aplurality of data environments, wherein the host computer systemcomprises: receiving means for receiving information identifying aspecific rule that reflects a discrepancy among the plurality of dataenvironments; searching means for searching the active data records fortelephone numbers relating to the specific rule; and transmitting meansfor transmitting a command to one of the plurality of data environmentsto change the status of each of the telephone numbers relating to thespecific rule.
 16. The system of claim 15, wherein one of the dataenvironments relates to a telephone number inventory system.
 17. Thesystem of claim 16, wherein the telephone number inventory systemcomprises a Customer Number Manager product.
 18. The system of claim 15,wherein one of the data environments relates to a telephone numberporting management system.
 19. The system of claim 18, wherein thetelephone number porting management system comprises an Advanced ServiceManagement System.
 20. The system of claim 19, wherein one of the dataenvironments relates to a service order system.